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FOREWORD 


This  report  summarizes  ARINC  Research  activities  described  in  Section 
4.3,  Statement  of  Work,  of  Contract  F33657-79-C-0475.  The  technical  effort 
addressed  the  development  of  the  architecture  for  mechanizing  the  program 
tracking  system  used  by  the  Deputy  for  Avionics  Control  (ASD/AX)  in  the 
Avionics  Master  Plan  (AMP)  preparation  and  in  the  avionics  control  func- 
tion. The  tracking  system  methodology  was  previously  developed  by  ARINC 
Research  under  Contract  F04606-76-A-0087/SG04. 

The  effort  described  in  this  document  was  sponsored  by  the  Aeronautical 
Systems  Division,  Deputy  for  Development  Planning  (ASD/XRE) . The  material 
presented  is  to  be  utilized  by  the  ASD  Data  Processing  facility  (ADP)  ir. 
its  coding  and  imp lamentation  of  the  AMP  data  base  storage  and  retrieval 
program  on  the  DEC  PDP  11T60  computer  for  use  by  the  Deputy  for  Avionics 
Control. 


iii 
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CHAPTER  ONE 


INTRODUCTION 


1.1  SCOPE 

This  report  summarizes  the  results  of  ARINC  Research  technical  activity 
sponsored  by  the  U.S.  Air  Force  under  Contract  F33657-79-C-0475 , Statement 
of  Work,  Section  4.3.  This  activity  included  the  development  of  the  archi- 
tecture for  mechanizing  the  program  tracking  system  used  by  the  Deputy  for 
Avionics  Control  (DAC)  in  the  Avionics  Master  Plan  (AMP)  preparation  and 
in  its  avionics  control  function. 

The  methodology  for  the  referenced  program  tracking  system  was  pre- 
viously developed  by  ARINC  Research  under  Contract  F04606-76-A-0087/SG04 
and  is  described  in  our  publication  1968-01-2-1944  of  June  1979.  The  major 
thrust  of  the  current  effort  was  to  adapt  the  methodology  to  a computerized 
system  that  would  provide  the  DAC  with  a powerful  and  useful  data  base  storage 
and  retrieval  tool.  Our  work  was  limited  to  software  architecture  develop- 
ment and  the  results  will  be  used  by  the  ASD  Data  Processing  Facility, 
which  will  code  and  implement  the  data  base  system  program  on  the  DEC  PDP 
11T60  computer. 


1.2  BACKGROUND 

AFR  800-28,  Avionics  Development  and  Support,  assigns  to  the  Deputy 
for  Avionics  Control  the  following  responsibilities : 

• Provide  a common  data  base  and  central  point  of  contact  for  all 
avionics  acquisition,  modification,  and  support  programs 

• Identify  new  programs  in  response  to  needs,  requirements , and 
directives 

• Ensure  that  planned  avionics  systems  are  compatible  with  existing 
and  other  planned  avionics  systems 

• Consider  the  use  of  common  avionics  equipment  in  all  new  aircraft 
systems 

• Assess  on-going  and  proposed  avionics  developments 

• Identify  needed  trade-off,  cost  benefit,  or  simulation  studies  and 
ensure  that  they  use  a common  data  base 
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Develop  and  maintain  the  Air  Force  Avionics  Master  Plan 


In  order  for  the  DAC  to  perform  the  avionics  controlling  function 
described  above,  it  was  recognized  that  a single  and  centralized  data  base 
maintained  by  the  DAC  and  containing  current  information  on  avionics  pro- 
grams was  required.  It  was  further  determined  that  the  data  base  should 
be  mechanized  so  that  the  data  could  be  utilized  and  updated  promptly  by 
the  DAC  without  an  undue  burden  on  manpower  resources.  The  resulting 
architecture  presented  in  this  report,  when  implemented,  will  provide  the 
required  data  base  capability. 


1.3  TECHNICAL  TASKS 


Our  contractual  requirement  is  to  develop  the  architecture  for  mech- 
anizing the  program  tracking  system  used  by  the  DAC  in  the  AMP  preparation 
and  in  the  avionics  control  function.  The  statement  of  work  stipulates 
that  ARINC  Research  is  to  perform  the  following  tasks: 


Design  and  define  the  data  base  and  describe  the  input  and  output 
processes  and  algorithms  required  for  data  presentation,  manipula 
tion,  and  updating 

Document  the  results  in  a summary  report 


In  addition  to  the  contractual  requirements,  we  were  provided  with  the 
following  additional  guidance: 


The  architecture  developed  should  be  compatible  with  and  suitable 
for  programming  on  the  DEC  PDP  11T60  computer. 

The  data  base  should  contain  only  the  data  needed  by  the  DAC  to 
perform  analyses  or  to  compile  supporting  material  for  development 
of  an  avionics  investment  strategy  and  for  influencing  decisions 
related  to  avionics  control. 

The  data  base  should  complement  to  the  maximum  extent,  rather  than 
duplicate,  information  contained  in  the  Avionics  Planning  Baseline 
data  base. 


1 . 4 TECHNICAL  APPROACH 


We  used  the  results  of  a previous  effort  — the  development  of  the  AMP 
Implementation  and  Tracking  System  Methodology  — as  a starting  point  for 
this  work.  We  also  considered  the  architecture  of  the  Avionics  Planning 
Baseline  data  base  as  a model  from  which  to  begin  development  of  this  data 
base . 


The  logical  data  base  record  compatible  with  the  PDP-11  was  designed 
and  a general  form  was  prepared  to  be  used  for  inputting  avionics  program 
data  suitable  for  keypunching. 


Discussions  with  ASD/AXP  were  held  to  determine  what  specific  types 
of  output  the  DAC  might  require  from  this  data  base.  Example  output  pre- 
sentations were  then  devised  and  the  data  manipulation  processes  required 
to  produce  these  data  summaries  were  developed.  Logic  diagrams  depicting 
the  process  are  presented  in  the  report. 


In  the  interest  of  flexibility,  the  data  base  architecture  was  also 
designed  so  that  more  general  sorting/screening  of  the  data  may  be  accom' 
plished  to  support  specific  user  needs  not  covered  by  the  overall  data 
summary  formats. 


While  it  is  expected  that  the  data  base  will  initially  be  accessed 
through  an  indirect  batch  processing  method,  the  concept  of  a real  time 
interactive  mode  of  data  base  access  using  a terminal  and  a "conversational 
approach  to  data  requests  is  possible  with  this  architecture. 


1 . 5 REPORT  ORGANIZATION 


The  remainder  of  this  report  is  organized  into  the  following  sections 


Chapter  Two  describes  the  data  base  architecture  including  input 
and  output  processing,  data  base  record  format,  and  a sample  data 
input  sheet. 

Appendix  A contains  logic  diagrams  and  related  program  sequence 
statements  describing  the  details  of  the  data  input  processing 
methodology  and  algorithms. 

Appendix  B contains  logic  diagrams  and  related  program  sequence 
statements  describing  the  data  output  processing,  including 
software  algorithms  for  producing  selected  data  summaries. 

Appendixes  C and  D contain  lists  of  abbreviations  and  codes  that 
should  be  used  for  inputting  avionics  program  data  and  creating 
the  AMP  data  base.  These  will  permit  comments,  titles,  and  long 
alphanumeric  symbols  to  be  coded,  printed,  and  stored  in  a concise 
manner. 
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CHAPTER  TWO 


DEVELOPMENT  OF  THE  AVIONICS  MASTER  PLAN 
DATA  BASE  ARCHITECTURE 

I 


2.1  INTRODUCTION 

This  chapter  describes  the  basic  architecture  for  a computerized 
Avionics  Master  Plan  (AMP)  program  tracking  system  data  base.  The  data 
base  has  been  designed  to  provide  the  Deputy  for  Avionics  Control  (DAC) 
with  a flexible  management  tool  that  will  assist  in  the  development  of 
an  avionics  investment  strategy  for  the  AMP  and  in  tracking  the  progress 
of  avionics  programs  represented  by  this  strategy. 

It  is  the  intent  that  the  results  presented  in  this  report  will  be 
used  by  ASD/ADP  as  the  basis  for  developing  the  program  code  to  implement 
the  data  base  storage  and  retrieval  system  and  by  ASD/AXP  in  the  creation 
and  update  of  the  mechanized  AMP  data  base  itself. 


2.2  OVERVIEW  OF  DATA  BASE  STRUCTURE 

This  data  system  is  a portion  of  a comprehensive  data  base  being 
developed  by  the  Deputy  for  Avionics  Control. 

As  currently  envisioned,  the  data  base  will  consist  of  three  structured 
files  as  depicted  in  Figure  2-1:  an  aircraft-oriented  file,  representing 
the  present  planning  status  by  each  aircraft  type  shown  in  the  force  struc- 
ture over  the  next  fifteen  years;  an  equipment-oriented  file,  providing 
additional  details  on  specific  equipments  installed  or  planned  to  be  in- 
stalled on  these  aircraft;  and  a program-oriented  file,  which  represents 
the  status  and  future  application  of  programs  proposed  for  the  current 
budget  year  and  subsequent  years. 

The  aircraft-oriented  file  is  being  employed  for  two  primary  purposes. 
One  is  to  update  the  current  Avionics  Planning  Baseline  (APB) , using  a 
print  format  similar  to  that  of  the  current  manually  produced  publication. 
Another  is  to  make  retrievals  assessing  the  effect  of  changes  to  input 
parameters  such  as  force  structures  and  installation  schedules.  This 
portion  of  the  data  base  has  been  established  by  the  ASD  computer  center 
(ASD/ADP). 
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The  output  of  the  equipment-oriented  file  is  to  be  used  as  an  analytic 
tool  for  cost  forecasts  and  to  develop  cost-estimating  relationships  (CERs) . 
These  data  must  be  passed  initially  through  a series  of  algorithms  for 
normalizing  the  data  to  the  same  fiscal  year  baseline,  the  same  cost- 
quantity  baseline,  and  other  pertinent  qualifiers  such  as  class,  size, 
and  reliability  of  the  equipment  and  the  associated  line  replaceable  units 
(LRUs) . 

The  output  of  the  program-oriented  file,  which  is  the  subject  of  this 
report,  is  envisioned  to  be  available  in  two  formats.  One  is  a tabular 
listing  essentially  matching  the  input  format.  The  second  is  one  of  several 
presentations  of  these  data  in  summary  format.  The  first  format  output  will 
be  used  as  an  appendix  to  the  annual  Avionics  Master  Plan.  The  second  format 
is  to  be  used  as  a basis  for  interpreting  the  effect  of  program  cancellations, 
schedule  shifts,  and  the  like. 

At  the  present  time,  it  is  contemplated  that  the  data  system  will  be 
implemented  by  means  of  the  PDP-11  configuration  installed  in  the  computer 
center.  Our  architecture  has  been  based  on  optimum  packing  of  data  in 
128-byte  records  suitable  for  floppy  disc  storage.  Interfaces  between 
the  three  primary  files  do  not  appear  to  be  necessary;  however,  commonality 
in  data  look-up  tables,  coding  language,  and  nomenclature  will  be  pre- 
served where  possible. 

The  following  sections  describe  the  architecture  as  it  relates  to 
various  facets  of  the  data  base  design,  i.e.,  data  base  input  (creation 
and  update)  and  data  base  output  (presentation).  Logic  diagrams,  tables, 
and  figures  supporting  these  areas  are  also  presented  in  the  appendixes, 
as  indicated. 


2 . 3 DATA  BASE  INPUT 

Although  the  data  base  will  be  sorted  on  various  fields  for  analyses, 
it  is  sequenced  in  the  computer  by  program  element,  project,  and  task. 

Data  will  be  entered  by  cards  into  the  master  data  base,  edited  for  proper 
card  format,  and  sorted  onto  the  master  data  base.  The  data  base  is  entered 
by  cards  keypunched  from  the  format  shown  in  Figure  2-2.  The  data  base  is 
then  used  by  various  programs  to  present  the  data  by  printed  output. 

The  data  input  process  involves  both  the  data  base  initialization 
(creation)  and  maintenance  (update).  The  update  function  consists  of 
changing  current  data,  deleting  data,  or  merging  new  data  into  the  current 
master  file.  Column  79  on  the  input  cards  is  used  to  denote  whether  the 
data  are  to  be  added  (A) , changed  (C) , or  deleted  (D)  from  the  data  base. 

In  all  cases  the  edit  capability  will  validate  the  input  data  for  proper 
format,  list  any  cards  in  error,  and  print  the  entire  new  master  data  base 
including  those  data  accepted  for  and  entered  into  the  master  file.  De- 
tailed descriptions  of  the  input  process,  including  logic  diagrams  and 
program  sequence  statements,  are  contained  in  Appendix  A. 
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DATA  INPUT  CODING  FORM 


The  card  input  process  uses  four  card  types.  Each  card  has  the  card 
type  printed  in  column  1 and  the  identifying  program  element,  project, 
and  task  in  columns  2 through  13.  Column  80  is  used  to  number  each  card 
type  in  sequence.  This  is  necessary  when  multiple  cards  are  required 
for  a given  sequential  file  data  record.  Tables  2-1  through  2-5  present 
the  descriptions  and  notational  conventions  for  the  identifying  data 
elements.  We  suggest  that  alphanumeric  data  entered  into  the  coding  form 
be  left- justified  and  numeric  data  be  right- justified.  The  notations  cited 
may  be  modified  or  enhanced  as  the  development  of  the  data  base  evolves 
and  are  not  intended  to  be  all-inclusive  at  this  time. 

Each  of  the  four  card  types  is  described  below. 

2.3.1  Card  Type  1 

In  addition  to  the  identifiers,  Card  Type  1 contains  the  text  for  the 
title  in  columns  14  through  33,  and  source  of  need  or  requirement  in 
columns  34  through  52.  There  is  no  sorting  on  these  fields.  The  "1st 
year  of  funding  input",  columns  53-54,  is  used  to  enable  the  computer  pro- 
gram to  align  the  funding  year  on  Card  Type  2.  That  is,  if  the  first  year 
of  funding  input  is  1981,  the  funds  for  year  1 will  be  stored  in  the  data 
base  table  under  1981;  the  funds  for  year  2 will  be  stored  under  1982, etc. 

The  road  map,  identified  in  columns  55  through  59,  is  the  avionics 
functional  area  planning  road  map  to  which  the  program  can  be  related  and 
is  a field  that  can  be  sorted.  The  associated  path  and  node  are  contained 
in  columns  60  through  64.  The  codes  to  be  used  for  identifying  road  maps 
are  presented  in  Table  2-2.  Additional  codes  generated  for  other  road 
maps  developed  should  not  exceed  five  characters. 

The  priorities  are  broken  down  into  a mission  need  value,  columns  65 
and  66,  and  an  economic  need  value,  columns  70  and  71.  An  overall  figure- 
of-merit  can  be  calculated  from  these  two  priorities , but  is  not  considered 
here.  However,  columns  75  through  78  may  be  used  in  the  future  for  this 
purpose.  The  coded  rationale  for  the  mission  need  is  in  columns  67  through 
69,  and  the  rationale  for  economic  need  is  in  columns  72  through  74. 

There  may  be  one  or  two  additional  type  1 cards  to  allow  for  multiple  road 
map  effects  on  a given  program.  For  the  additional  type  1 cards,  the  card 
type,  program  element,  project,  and  task  must  be  entered  as  well  as  the 
road  map,  path,  and  node  information.  The  remainder  of  the  card  can  be 
left  blank.  Table  2-2  presents  the  data  element  descriptions  and  notations 
for  Card  Type  1. 

2.3.2  Card  Type  2 

In  addition  to  the  identifiers,  program  element,  project,  and  task. 
Card  Type  2 contains  data  related  to  funding  for  up  to  ten  years  in 
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Table  2-1.  LATA  ELEMENT  DESCfclPTlUNS  A MU  NOTATl UMAL  COHVEHTIOH 
Ft*  LATA  INPUT  COHNON  TU  ALL  PCUK  CARD  TYPEb 


(STCC)  , Test  and  Evaluation  (TE),  Software 
Policy  (SUP),  Software  Model  (SUM),  Software 
Testing  (SWT) , Software  Sunort  (SWS)  . 


Tat  It:  2-2.  <cor*t  ifMjed) 


columns  14  through  63.  If  additional  years  of  funding  are  to  be  entered, 
one  additional  Card  Type  2 may  be  used.  In  this  case,  the  "year  1"  field 
will  actually  be  interpreted  as  "year  11";  "year  2"  will  be  interpreted 
as  "year  12",  etc.  when  two  cards  are  needed,  columns  64  through  78  can 
remain  blank  on  the  second  card. 

In  general,  estimated  or  recommended  funding  that  is  not  yet  approved 
must  be  entered  as  a negative  value.  When  output,  the  value  will  be 
printed  in  parentheses  to  distinguish  it. 

The  program  status  is  entered  in  columns  64  and  65;  PEM,  in  columns 
66  through  70;  and  the  technical  monitor,  in  columns  71  through  78. 

A blank  entered  for  any  funding  year  will  be  printed  as  a blank. 
Th®*efore,  if  a zero-level  of  funding  (approved  or  recommended)  is  the 
desired  response,  "0"  should  be  entered  as  appropriate.  Table  2-3  pre- 
sents the  data  element  descriptions  and  notations  for  Card  Type  2. 

2.3.3  Card  Type  3 

In  addition  to  program  element,  project,  and  task  identifiers,  Card 
Type  3 contains  the  weighted  allocation,  mission  area,  and  aircraft  type 
for  up  to  five  allocations.  The  allocation  is  a four-place  decimal  amount, 
with  the  decimal  point  understood  (.XXXX).  An  allocation  of  1.0  can 
also  be  inserted  in  this  field.  For  each  allocation,  there  is  a mission 
area  (up  to  5 characters)  and/or  a coded  aircraft  type  (3-digit  code,  see 
Appendix  D) . There  may  be  a maximum  of  two  type  3 cards.  Table  2-4 
presents  the  data  element  descriptions  and  notations  for  Card  Type  3. 

2.3.4  Card  Type  4 (Optional) 

In  addition  to  the  program  element,  project,  and  task  identifiers. 

Card  Type  4 uses  columns  14  through  77  for  comments.  The  reference  to  a 
previous  program  element  for  follow-on  or  consolidated  programs  should  be 
noted  in  the  comments  field.  At  present  only  two  type  4 cards  will  be 
maintained  in  the  data  base.  The  use  of  abbreviations  is  encouraged.  Table 
2-5  presents  a brief  description  of  the  data  for  Card  Type  4. 


2.4  MASTER  DATA  BASE  RECORD  FORMAT 

Table  2-6  presents  the  recommended  data  base  record  format  for  the 
master  data  storage.  When  its  form  has  been  approved,  it  will  be  used 
during  both  input  and  output  processing. 

It  is  envisioned  that  floppy  disks  will  be  used  for  data  base  storage. 
The  data  base  record  format  is  designed  in  block  increments  of  128  bytes,  if 
a particular  program  element  data  set  requires  no  type  4 cards  and  only 
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LOGICAL  DATA  &A£E  MCCORD  FORMAT 
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4 


Bytus 

Primary  Data  Block  Data  Elamant 

1-6 

Program  Elsmant/Nodlflcatlon  Nampa r 

7-10 

Projact.'Budoat  Coda 

11-12 

Task/ Modification  Class 

11-12 

Titla 

11-51 

So  urea  of  Haad  or  Raquiramant 

52-5  J 

first  Yaar  of  Fundinq 

54-68 

Road  Map 

59-61 

Path 

62-61 

Noda 

64-65 

MSN  Naad  (Priority! 

66-68 

Rationala  (MSN  Priority) 

69-70 

Economic  Naad  (Priority) 

-1-7  J 

Rationala  (ICON  Priority) 

74-78 

1980  Fundinq 

79-81 

1981  Fundinq 

84-88 

1982  Fundinq 

84-41 

1481  Fundinq 

84-48 

1484  Fundinq 

99-101 

1485  Fundinq 

174-108 

I486  Fundinq 

109-111 

1987  Fundinq 

114-118 

1988  Fundinq 

119-121 

1989  Fundinq 

124-128 

1990  Fundinq 

129-111 

1991  Fundinq 

114-118 

1992  Fundinq 

119-141 

1991  Fundinq 

144-148 

1994  Fundinq 

144-161 

1946  Fundinq 

164-168 

1496  Fundinq 

154-161 

1947  fundinq 

164-168 

1498  Fundinq 

164-171 

1994  Fundinq 

174-176 

Proqram  Status 

176-180 

PEN 

181-188 

Tachmcal  Monitor 

184-192 

Allocation  (1) 

191-197 

MSN  Naad  (1) 

198-200 

ACFT  Typa  (Codad)  (1) 

201-204 

Allocation  (2) 

205-209 

MSN  Naad  (2) 

210-212 

ACFT  Typa  (Codad)  (2) 

211-216 

Allocation  (1) 

2i’-22l 

MSN  Naad  (1) 

222-224 

ACrT  Typa  (Codad)  (1) 

225-228 

Allocation  (4) 

Bytas 

Primary  Data  Block  Data  Clamant 

229-211 

MSN  Naad  (4) 

214-216 

ACFT  Typa  (Codad)  (4) 

217-240 

Allocation  (5) 

241-245 

MSN  Naad  (5) 

246-248 

ACFT  Typa  (Codad)  (5) 

249-264 

Futura  Growth  4 

255 

Additional  Block  Indicator 

(For  optional  Typa  4 Card  data) 

256 

Additional  Block  Indicator* 

(For  optional  Typa  1 and/or  Typa 
Card  data) 

Additional  Data  Block 

for 

Optional  Typa  1 and  Typa  1 Cards 

1-4 

Allocation  (6) 

5-9 

MSN  Araa  (6) 

10-12 

ACFT  Typa  (Codad)  (6) 

11-16 

Allocation  (71 

17-21 

MSN  Araa  (7) 

22-24 

ACFT  Typa  (Codad)  (7) 

25-28 

Allocation  (8) 

24-31 

MSN  Araa  (8) 

14-16 

ACFT  Typa  (Codad)  (8) 

17-40 

Allocation  (9) 

41-45 

MSN  Araa  (9) 

46-48 

ACFT  Typa  ICodad)  (9) 

49-52 

Allocation  (10) 

51-57 

MSN  Araa  (10) 

58-60 

ACFT  Typa  (Codad)  (10) 

61-65 

Sacond  Road  Map 

66-68 

Sacond  Path 

69-70 

Sacond  Noda 

71-75 

Third  Road  Map 

76-78 

Third  Path 

79-80 

Third  Noda 

81-128 

Futura  Growth 

Additional  Data  Block 
for  Optional  Typa  4 Cards 

1-64  Commants  (First  Typa  4 Card) 
66-128  Common ts  (Sacond  Typa  4 Card) 


*Nhan  both  additional  data  block  typa a axist  In  a racord,  tha  block  conslatinq  of 
Typa  1 and  Typa  1 Card  data  will  always  appaar  first. 


* 
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one  type  1 and  one  type  3 card, a basic  256-byte  block  is  required 
additional  128-byte  block  is  required  in  either  of  two  cases: 


One  or  two  type  4 "Comments"  cards  are  used. 
Additional  or  optional  type  1 and  3 cards  are  used 


Therefore,  the  record  size  for  any  particular  program  element/project/task 
sequence  may  be  256,  384,  or  512  bytes  depending  on  the  quantity  of  input 
data.  Bytes  255  and  256  in  the  basic  block  are  used  to  indicate  the  record 
size  and  the  nature  of  additional  blocks  "chained"  to  the  basic  block. 


This  approach  was  taken  to  maximize  utilization  of  disk  storage. 
However,  if  varying  the  record  sizes  makes  search  or  sorting  too  complex, 
consideration  should  be  given  to  forcing  consistency  of  record  size  to  512 
bytes  regardless  of  the  type  and  quantity  of  data  involved  for  a given 
prograra/pro ject  set. 


Normalizing  the  funding  data  to  the  same  fiscal  year  baseline 
facilitates  the  design  and  execution  of  the  sort  and  print  routines.  For 
example,  questions  concerning  the  statistics  for  funding  for  a particular 
year  are  easily  extracted.  The  flow  chart  for  converting  input  data  cards 
to  the  logical  data  base  records  is  shown  in  Figure  A-2  of  Appendix  A. 

Each  record  contains  funding  information  for  the  years  1980  through  1999, 
so  that  the  format  will  be  stable  for  several  years  of  use,  and  historical 
data  will  be  saved  automatically. 


2.5  DATA  BASE  OUTPUT  AND  PRESENTATION 


The  data  output  process  should  be  flexible  and  yet  responsive  to  the 
specified  user  needs.  In  addition  to  the  complete  listing  of  the  data  base 
records,  the  data  must  also  be  able  to  be  sorted  and  screened  to  permit 
the  creation  of  specialized  listings  of  data  for  use  in  selected  analyses 
or  for  use  as  appendixes  to  the  AMP.  The  proposed  data  elements  for  inclu- 
sion in  the  sorting  and  screening  process  are  identified  in  this  section. 


The  DAC  will  also  require  standard  data  summary  presentation  and  for- 
mats that  can  be  requested  repeatedly  without  requiring  any  special  coding 
Examples  of  data  summary  outputs  that  will  provide  general  program  visi- 
bility that  the  DAC  often  requires  are  presented  in  the  section  following. 
Appendix  B contains  detailed  logic  diagrams,  algorithms,  and  program 
sequence  statements  that  describe  the  process  for  producing  these  sum- 
mary data  presentations. 


There  are  many  combinational  possibilities  for  data  output.  It  is 
expected  that  a graphical  display  capability  will  be  developed  eventually 
for  summary  of  the  data.  We  have  selected  several  tabular  formats  designed 
for  direct  application  by  the  DAC.  Figures  2-3  through  2-7  show  suggested 
example  presentations  that  could  be  programmed  into  the  system  and  requested 


r 


by  a simple  instruction.  Funding  that  is  not  approved,  i.e.,  recommended 
or  estimated  funding,  is  displayed  in  parentheses ( ).  Currently,  the  total 

(is  also  placed  in  parentheses  whenever  any  element  of  the  sum  is  an  estimate 
or  recommendation.  Therefore,  the  total  represents  both  approved  and  recom- 
mended funding  requirements. 

To  maximize  data  base  flexibility,  specific  sorting  and  listing  of 
the  data  in  any  format  should  be  permitted  within  the  constraints  of  the 
output  printer.  Specific  requirements  of  the  output  structure  must  still 
be  determined,  but  it  is  recommended  that  the  following  data  fields  be 
included  in  any  sort  capability: 

* Mission  Area 
• Aircraft  Type 
• Mission  Need  (Priority) 

• Economic  Need  (Priority) 

• Program  Element/Mod  Number 
• Road  Map 
• Program  Status 

In  addition,  capability  to  retrieve  from  certain  data  fields  is  recom- 
mended. The  following  are  suggested  data  fields  and  screening  options: 

• Mission  Need  Priority  (>  or  < X) 

• Economic  Need  Priority  (>  or  < Y) 

• Aircraft  Type  (Specify  only  those  to  be  included) 

• Mission  Area  (Specify  only  those  to  be  included) 

• Program  Status  (Specify  only  those  to  be  included) 

• Program  Element  (Specify  first  two  digits  of  class  of  programs  to 
be  included)  or  Modification  Class  (Specify  IV  or  V) 

• Year  of  Funding  (Specify  years  or  interval  over  which  funding  is 
to  be  included) 

• Road  Map  (Specify  only  functional  areas  to  be  included) 

With  no  screening  criteria  specified,  a comprehensive  listing  cf  the 
data  base  will  result. 

Details  relating  to  the  mechanisms  for  implementing  the  sorting  and 
screening  options  are  to  be  developed  by  the  DAC  subsequent  to  this  effort. 


2.6  SIZING  OF  THE  DATA  BASE 


Our  review  of  the  current  five-year  defense  plan  reveals  that  approx- 
imately 140  data  records  will  be  required  to  accommodate  the  avionics- 
related  program  elements  (PEs)  and  their  associated  projects.  Each  project 
requires  a separate  data  record.  In  addition  to  the  currently  approved 
PEs,  it  is  expected  that  the  data  base  will  contain  up  to  100  proposed 
programs  under  the  notation  "62XXX" , "64YYY" , etc.  Under  the  worst-case 
assumption,  we  estimate  that  the  data  base  should  be  sized  as  follows: 

140  PEs  x 4 blocks  x 128  bytes/block  * 71,680  bytes 

100  PEs  x 3 blocks  x 128  bytes/block  = 38,400  bytes 

Total  bytes  = 110,080  bytes 

Thus  the  data  base  can  reside  on  one  128K  byte  floppy  disk  and  allow  for 
some  future  expansion. 

We  further  estimate  that  when  the  data  for  aircraft  modification  pro- 
grams are  added  to  the  data  base,  they  will  require  approximately  70,000 
bytes.  Therefore,  it  is  not  possible  to  include  them  on  the  same  128K  byte 
disk  with  the  KDT&E  program  data.  A separate  disk  would  be  required.  If 
the  disk  will  hold  256K  bytes,  a combination  of  the  program  data  may  be 
desirable. 
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APPENDIX  A 


INPUT  PROCESSING  LOGIC  DIAGRAMS  AND  PROGRAM 
SEQUENCE  STEP  DESCRIPTIONS 


This  appendix  contains  detailed  logic  diagrams  and  program  sequence 
step  descriptions  for  the  Avionics  Master  Plan  data  base  input  processing. 

The  intent  of  Figure  A-l  is  to  show  a macro-level  view  of  the  input 
process  for  the  data  base  initialization  and  maintenance . It  shows  assembly 
of  the  various  card  types,  1,  2,  3,  and  4,  for  one  program  element,  project, 
and  task,  and  shows  the  master  data  base.  This  diagram  also  depicts  the 
overall  card  input  verification  and  editing  routine  used  in  a batch  mode 
of  operation. 

The  flow  in  Figure  A-2  is  a further  breakdown  and  is  more  specific 
than  the  flow  of  Figure  A-l. 

Tables  A-l  and  A-2  present  a listing  of  sequential  program  statements 
that  follow  the  logic  flow. 
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Table  A-l . TABLE  OF  PROGRAM  STATEMENTS  FOR  THE 

LOGIC  DIAGRAM  IN  FIGURE  A-l. 

Sequential 
Step  Number 

Program  Statement 

1. 

Initializing  the  Data  Base 

Do  until  end  of  input.  When  done,  go  to  Step  5. 

2. 

Read  input  card. 

3. 

Check  for  valid  fields  as  designated  by  the  specific  card 

4.0 

type  format. 

If  validity  checks  do  not  pass, 

4.10 

Then  print  card  data  on  error  list. 

4.15 

Go  to  Step  2. 

4.20 

Else  copy  card  onto  file. 

4.25 

Go  to  Step  2. 

5. 

Sort  data  base  by  program  element,  project,  task,  card  type. 

6. 

Read  sorted  cards  and  store  appropriate  fields  in  output 

7. 

file  for  master  data  base. 

Print  master  data  base. 

1. 

Maintaining  the  Data  Base 

Do  until  end  of  input.  When  done,  go  to  Step  5. 

2. 

Read  input  card. 

3. 

Check  for  valid  fields  as  designated  by  the  specific  card 

4.0 

type  format. 

If  validity  checks  do  not  pass. 

4.10 

Then  print  card  data  on  error  list 

4.15 

and  go  to  Step  2. 

4.20 

Else  copy  card  onto  file. 

4.25 

Go  to  Step  2. 

5. 

Sort  update  data  by  program  element,  project,  task,  card 

6. 

type. 

Do  until  end  of  update  file.  When  done,  go  to  Step  11. 

7. 

Read  update  record  (equivalent  to  one  input  card) . 

8.0 

If  column  79  * C (Change) , 

8.10 

Then  read  record  of  master  data  base . 

8.20 

Match  on  program  element,  project,  task,  card  type. 

If  master  record  is  less  than  update  record, 

8.25 

Then  write  master  record  onto  new  master. 

8.30 

Go  to  Step  8 . 10 

8.35 

If  master  record  is  equal  to  update  record. 

8.40 

Then  write  update  record  onto  new  master.. 

8.45 

Go  to  Step  7. 

8.50 

If  master  record  is  greater  than  update  record. 

8.55 

Then  write  update  record  onto  Error  List. 

Table  A-l . (continued) 

Sequential 
Step  Number 

Program  Statement 

Maintaining  the  Data  Base  (continued) 

8.60 

Go  to  Step  7. 

9.0 

If  Column  79  * D (Delete) , 

9.10 

Then  read  record  of  master  data  base. 

9.15 

Match  on  program  element,  project,  task,  card  type. 

9.20 

If  master  record  is  less  than  update  record, 

9.25 

Then  write  master  record  onto  new  master. 

9.30 

Go  to  Step  9.10 

9.35 

If  master  record  is  equal  to  update  record. 

9.40 

Then  go  to  Step  7. 

9.45 

If  master  record  is  greater  than  update  record. 

9.50 

Then  write  update  record  onto  error  list 

9.55 

Write  master  onto  new  master. 

9.60 

Go  to  Step  7. 

10.0 

If  Column  79  = A (Add  or  Merge) , 

10.10 

Then  read  record  of  master  data  base. 

10.15 

Match  on  program  element,  project,  task,  card  type. 

10.20 

If  master  record  is  less  than  update  record. 

10.25 

Then  write  master  record  onto  new  master. 

10.30 

Go  to  Step  10.10 

10.35 

If  master  record  is  equal  to  update  record. 

10.40 

Then  write  update  record  onto  error  list. 

10.45 

Write  master  record  onto  error  list. 

10.50 

Write  update  record  onto  new  master. 

10.55 

Go  to  Step  7. 

10.60 

If  master  record  is  greater  than  update  record, 

10.65 

Then  write  update  record  onto  new  master. 

10.70 

Write  master  record  onto  new  master. 

10.75 

Go  to  Step  7. 

11.0 

Do  until  end  of  master  file.  When  done,  exit. 

11.10 

Read  master  record. 

11.15 

Write  master  record  onto  new  master. 

11.20 

Go  to  Step  11.10. 

Check 

Card 

Type 


Read 

Card 


Sort  on  Program 
Element,  Project, 
Teak,  Card  Type 
(Column  1) 


Print  Card 
on  Error 
List 


Verify  Data 
for  Legal 
Numeric 
Fields 


V 


Move  Columns 
>64  to  Output* 
1-63,  Move  Columns 
65-74  to  Output 
64-73 


Move  Columns 
55-64  to 

"1“ 

Card 

^ Not  ”1" 



Print 

Are< 



Output 

on 

Additional 
Output  Area 

> or  "2W 

Error 

List 

•Output  refers  to  computer  Master  Data  Data  Base  Pecord.  See  Table  3-6  for 
byte  allocations. 

Figure  A-2.  DETAILED  FLOW  DIAGRAM 
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Figure  A-2 . (continued) 
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Not*:  Te»t*  must  be  made  to  determine  that  the  maximum  allowable  number  of  cards  of  any  type  has  not 
been  exceeded  for  a given  program  element  record. 


APPENDIX  B 


DATA  OUTPUT  LOGIC  DIAGRAMS,  ALGORITHMS,  AND 
PROGRAM  SEQUENCE  STEP  DESCRIPTIONS 


This  section  contains  detailed  logic  diagrams,  algorithms,  and  program 
sequence  steps  for  producing  the  output  data  summaries  described  in  Section 
2.5  of  Chapter  Two. 

The  logic  flow  and  program  statement  sequence  shown  in  Figure  B-l, 
when  implemented,  will  produce  any  of  the  three  output  summaries  shown 
previously  in  Figures  2-3,  2-4,  and  2-5  in  Chapter  Two. 

Figures  B-2  and  B-3  provide  the  logic  diagrams  and  program  statement 
sequences  associated  with  the  preparation  of  the  summary  data  previously 
shown  in  Figures  2-6  and  2-7,  respectively. 


Table  B-l.  STEPS  TO  PRINT  SUMMARY  FUNDS  ACCUMULATED  FOR 

MISSION  AREA,  AIRCRAFT  TYPE,  OR  PROGRAM  STATUS* 


Sequential 
Step  Number 


Program  Statement 


1.  Input  to  program:  data  base  sorted  by  mission  area,  or 
aircraft  type,  or  program  status,  as  is  appropriate. 

2.  Initialize  line  and  page  counters,  initialize  fund 
accumulators . 

3.  Print  report  headings. 

4.  Read  two  records  for  one  logical  record,  256-bytes. 

5.  Save  ID  equal  to  mission  area,  aircraft  type,,  or  program 
status. 

6.  Add  funds  from  data  base  to  accumulators. 

7.  If  no  additional  block  indicators  are  on  (bytes  255,  256), 
Then  go  to  step  8. 

Else** 

1 

8.  Read  two  records  for  one  logical  record,  256  bytes. 

At  end  of  file,  set  EOF  flag. 

9.  If  ID  of  previous  record  is  equal  to  ID  of  present  record, 
go  to  Step  6. 

10.  Sum  accumulators  to  totals. 

11.  Print  ID,  accumulators,  and  total. 

12.  Check  line  counter  and  do  new  page  routine  if  necessary. 

13.  Initialize  fund  accumulators. 

14.  If  EOF  flag  is  set,  print  final  totals  and  exit. 

15.  Else  go  to  Step  5. 

*The  flow  for  the  three  funds-accumulated  summary  routines  is  the  same. 

**Logic  to  test  for  existence  of  relevant  additional  data  block  (byte  256 
on)  before  proceeding  to  Step  8 is  required.  Otherwise  the  additional 
block  specified  by  byte  255  can  be  skipped  (see  Table  2-6) . 


Figure  B-2.  ROUTINE  TO  PRINT  FUNDING  SUMMARY  BY  PROGRAM 


i 
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Table  B-2.  STEPS  TO  PRINT  SUMMARY  FUNDING  BY  PROGRAM 

Sequential 
Step  Number 

Program  Statement 

1. 

Input  to  program:  data  base  sorted  by  program  element. 

2. 

Initialize  line  and  page  counters. 

3. 

Print  report  headings. 

4. 

Read  two  records  for  one  logical  record,  256  bytes. 

5. 

If  end  of  file,  exit. 

6. 

Move  appropriate  fields  to  output  area. 

7. 

Convert  negative  funding  amounts  to  values  enclosed  by 
parentheses. 

8. 

Accumulate  funding  for  years  1980-1984.  If  any  were  negative, 
enclose  total  in  parentheses. 

9. 

Print  line. 

10. 

Update  line  counters  when  line  counter  equals  maximum  line 
count . 

Do  new  page  routine,  increment  page  counter,  initialize  line 
counter . 

11. 

If  no  additional  block  indicators  sure  on,  go  to  Step  4. 

Else* 

12. 

Read  128-byte  record. 

13. 

If  there  are  additional  aircraft  and  mission  area  fields, 
move  to  output  and  print  line. 

14. 

Go  to  Step  4. 

*Logic  to  test  for  existence  of  relevant  additional  data  block  (byte  256  on) 

before  proceeding  to  Step  12  is  required.  Otherwise  the  additional  block 

specified  by  byte  255  can  be  skipped  (see  Table  2-6) . 
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Table  B-3.  PROGRAM  ELEMENT  SORT  REPORT* 

Sequential 

Step  Number 

Program  Statement 

1. 

Initialize  the  line  and  page  counters. 

2. 

Print  the  headings. 

3. 

Read  two  128-byte  data  blocks  for  a logical  record  of  256 

bytes . 

4. 

If  end-of-file  condition  is  reached,  exit. 

5. 

If  line  counter  equals  maximum  number  of  lines  per  page, 

Then  print  headers  on  new  page. 

update  page  counter, 

initialize  line  counter. 

6. 

Move  appropriate  data  base  fields  to  output  area  and  print 

line  of  data  after  one  space. 

7. 

If  no  additional  block  indicators  are  on,  go  to  Step  3. 

Else** 

8. 

Read  additional  data  block  of  128  bytes 

9. 

If  additional  road  map,  path,  and  node  data, 

then  move  these  fields  to  output  area. 

10. 

If  additional  coded  aircraft  type  specified, 

then  do  translation  of  code  to  aircraft  and  move  these 

fields  to  output  area. 

11. 

If  output  area  is  not  blank, 

print  from  output  area. 

12. 

Go  to  Step  3. 

*The  data  base  is  assumed  to  be  sorted  by  program  element,  project,  and 
task. 


**Logic  to  test  for  existence  of  relevant  additional  data  block  (byte  256 
on)  before  proceeding  to  Step  8 is  required.  Otherwise  the  additional 
block  specified  by  byte  255  can  be  skipped  (see  Table  2-6) . 
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APPENDIX  C 


LIST  OF  SUGGESTED  ABBREVIATIONS 
FOR  CONCISE  DATA  INPUT  CODING 


Appendix  C lists  general  abbreviations  to  be  used  with  the  program 
tracking  system  for  the  Avionics  Master  Plan. 
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LIST  OF  SUGGESTED  ABBREVIATIONS 
FOR  CONCISE  DATA  INPUT  CODING 


AAA 

A/C 

ADCOM 

AEEC 

AFAL 

AFLC 

AFR 

AFSATCOM 

AFSC 

AHARS 

AI 

AISF 

ALCM 

ALS  (MLS) 

ALSS 

AM 

AMP 

APB 

APC 

APG 

APVOI 

ARM 

ARPV 

ASF 

ATBM 

ATE 

ATF 

AWACS 

AWTSS 


Anti-Aircraft  Artillery 
Aircraft 

Air  Defense  Command 

Airlines  Electronic  Engineering  Committee 

Air  Force  Avionics  Laboratory 

Air  Force  Logistics  Command 

Air  Force  Reserve,  Air  Force  Regulation 

Air  Force  Satellite  Communications  (System) 

Air  Force  Systems  Command 

Attitude  Heading  and  Reference  System 

Airborne  Intercept 

Avionics  Integration  Support  Facility 
Air  Launched  Cruise  Missile 
Advanced  (Microwave)  Landing  System 
Advanced  Location  Strike  System 
Amplitude  Modulation 
Avionics  Master  Plan 
Avionics  Planning  Baseline 

Avionics  Planning  Conference,  Armored  Personnel  Carrier 

Avionics  Planning  Guidance 

Advanced  PVO  Interception 

Anti-Radiation  Missile 

Advanced  Remotely  Piloted  Vehicle 

Air  Superiority  Fighter 

Anti-Tactical  Ballistic  Missile 

Automatic  Test  Equipment 

Advanced  Tactical  Fighter 

Airborne  Warning  and  Control  System  (E-3  Sentry) 

All  Weather  Tactical  Strike  System 


BIT 

BITE 

BNS 


CAD 

CAR 

CAS 

C2 


Built- In-Test 
Built-In-Test  Equipment 
Bombing  Navigation  System 

Computer  Aided  Design 
Command  Assessment  Review 
Close  Air  Support,  Collision  Avoidance  System 
Command  and  Control 


C3I 

Command,  Control,  Communications,  and  Intelligence 

CCD 

Charge  Coupled  Device 

n 

C/D 

Controls  and  Displays 

CEP 

Circular  Error  Probable 

CERT 

Combined  Environmental  Reliability  Test 

n 

CIP 

Component  Improvement  Program 

CNPI 

Communications,  Navigation,  Positioning,  Identification 

COMM 

Communi cat ions 

_ . 

COMSEC 

Communications  Security 

CRAF 

Civil  Reserve  Air  Fleet 

- 

CW 

Continuous  Wave 

n 

DAC 

Deputy  for  Avionics  Control 

i 

• * 

DAIS 

Digital  Avionics  Information  System 

DF 

Direction  Finder 

• y 
J ft 

DID 

Data  Item  Description 

J 

OITS 

Digital  Information  Transfer  System 

DUE 

Distance  Measuring  Equipment 

* 

DNA 

Defense  Nuclear  Agency 

u 

DT&E 

Development,  Test  and  Evaluation 

EAA 

EAR 

ECM 

ECCM 

EHP 

EMC 

EMI 

EMP 

EMR 

EO 

ERP 

ESB 

ESM 

ETF 

EW 

EWI 

FAA 

FAC 

FCS 

FD/FI 

FEBA 

F3 

FIS 

FIT 

FLIR 

FLR 

FM 

F/W 


Enhanced  Airlift  Aircraft 
Electronically  Agile  Radar 
Electronic  Counter  Measure 
Electronic  Counter-Counter  Measure 
Electrical  Hazard  Protection 
Electromagnetic  Compatibility 
Electromagnetic  Interference 
Electromagnetic  Pulse 
Electromagnetic  Radiation 
Electro -Optical 
Effective  Radiated  Power 
Enhanced  Strategic  Bomber 
Electronic  Support  Measures 
Enhanced  Tactical  Fighter 
Electronic  Warfare,  Early  Warning 
Education  with  Industry 

Federal  Aviation  Agency 
Forward  Air  Controller 
Fire  Control  System 
Fault  Detection,  Fault  Isolation 
Forward  Edge  of  the  Battle  Area 
Form,  Fit,  Function 
Future  Identification  System 
Fault  Identification  Test 
Forward  Looking  Infrared 
Forward  Looking  Radar 
Frequency  Modulation 
Firmware 
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GBU 

Guided  Bomb  Unit 

GCI 

Ground  Controlled  Intercept 

GEANS 

Gimballed  Electrostatic  Aircraft  Navigation  System 

GEO REF 

world  Geographic  Reference  System 

GTE 

Government  Furnished  Equipment 

GLCM 

Ground  Launched  Cruise  Missile 

GOR 

General  Operational  Requirement 

GPS 

Global  Positioning  System 

GPWS 

Ground  Proximity  Warning  System 

GSF 

Ground  Support  Fighter 

HF 

High  Frequency 

HOL 

Higher  Order  Language 

HQ 

Headquarters 

ICAO 

International  Civil  Aviation  Organization 

ICNIA 

Integrated  Communications,  Navigation,  and  Identifi 
cation  Avionics 

ICS 

Interim  Contract  Support 

IDA 

Integrated  Digital  Avionics 

IFF 

Identification  Friend  or  Foe 

IFFN 

Identify  Friend,  Foe,  Neutral 

HR 

Imaging  Infrared 

ILS 

Instrument  Landing  System 

INS 

Inertial  Navigation  System 

IOC 

Initial  Operational  Capability 

IOT&E 

Initial  Operation,  Test  and  Evaluation 

IR 

Infrared 

IRCM 

Infrared  Counter  Measure 

J/S 

Jamming-to-Signal  Ratio 

JTIDS 

Joint  Tactical  Information  Distribution  System 

LCC 

Life  Cycle  Cost 

LGB 

Laser  Guided  Bomb 

LLLTV 

Low  Light  Level  Television 

LORAN 

Long  Range  Navigation 

LOS 

Line  of  Sight 

LPIR 

Low  Probability  of  Intercept  Radar 

LRA 

Long  Range  Aviation 

LRU 

Line  Replaceable  Unit 

LSI 

Large  Scale  Integration 

MAA 

Mission  Area  Analysis 

MAC 

Military  Airlift  Command 

MAJCOM 

Major  Command 

MATE 

Modular  Automatic  Test  Equipment 

MCF 

Military  Computer  Family 

MENS 

Mission  Element  Needs  Statement 

MFPA 

Monolithic  Focal  Plane  Array 
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MGRS 

Military  Grid  Reference  Systam 

MLS 

Microwava  Landing  Systam 

MM 

Minima  tar 

MOA 

Mamorandum  of  Agraamant 

MTBF 

Maan  Tima  Between  Failuras 

MTT 

Multipla  Target  Track 

MUX 

Multiplex 

NASA 

National  Aeronautics  and  Space  Administration 

NATO 

North  Atlantic  Treaty  Organization 

NAV 

Navigation 

NCA 

National  Command  Authority 

NMLS 

National  MLS 

NRL 

Naval  Research  Laboratory 

OAP 

Offset  Aim  Point 

OSS 

Operation  and  Support 

OCM 

Optical  Countermeasures 

OCCM 

Optical  Counts r-Countermeasures 

OFP 

Operational  Flight  Program 

OMB 

Office  of  Management  of  the  Budget 

PAR 

Program  Assessment  Review 

PAT 

Passive  Angle  Tracking 

POM 

Program  Decision  Memorandum 

PENAID 

Penetration  Aid 

PKSS 

Single  Shot  Probability  of  Kill 

PLSS 

Precision  Location  Strike  System 

PMD 

Program  Management  Directive 

PMRT 

Program  Management  Responsibility  Transfer 

POM 

Program  Objective  Memorandum 

POS 

Position 

PRAM 

Productivity,  Reliability , Availability,  Maintainability 

PSP 

Programmable  Signal  Processor 

PRF 

Pulse  Repetition  Frequency 

PVO 

Soviet  Air  Defense 

QA 

Quality  Assurance 

QSR 

Quick  Strike  Reconnaissance 

RCS 

Radar  Cross  Section 

RDTSE 

Research,  Development,  Test,  and  Evaluation 

RECCE,  RECON 

Reconnaissance 

RF 

Radio  Frequency 

RHAW 

Radar  Homing  and  Warning 

RLA 

Repair  Level  Analysis 

R/M 

Reliability  and  Maintainability 

RNAV 

Area  Navigation 

ROC 

Required  Operational  Capability 

RPV 

Remotely  Piloted  vehicle 

RRG 

Requirements  Review  Group 

RWR 

Radar  Warning  Receiver 
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SAB 

Scientific  Advisory  Board 

SAC 

Strategic  Air  Command 

SAM 

Surface-to-Air  Missile 

SAR 

Synthetic  Aperture  Radar 

SDA 

Strike  Director  Aircraft 

SC 

System  Effectiveness 

SCA 

Southeast  Asia 

SEP 

Spherical  Error  Probable 

sir 

Selective  Identification  Feature 

SIGINT 

Signal  Intelligence 

SIOP 

Single  Integrated  Operational  Plan 

SIT 

System  Integrated  Test 

SLAR 

Side  Looking  Airborne  Radar 

SLBM 

Submarine  Launched  Ballistic  Missile 

SM 

System  Manager 

SNA 

Soviet  Naval  Aviation 

SON 

Statement  of  Operational  Need 

SRAM 

Short  Range  Attack  Missile 

SRU 

Shop  Replaceable  Unit 

STOL 

Short  Take-Off  and  Landing 

STT 

Single  Target  Track 

SWT 

Search  while  Track 

TAC 

Tactical  Air  Command 

TACAN 

Tactical  Air  Navigation 

TAF 

Tactical  Air  Force 

TATI IS 

Tactical  Air  Forces  Integrated  Information  System 

TAIS 

Tactical  Air  Intelligence  System 

TfiE 

Test  and  Evaluation 

TCSGA 

Thermo  Condensation  Smoke-Generation  Apparatus 

TDMA 

Time  Division  Multiple  Access 

TEREC 

Tactical  Electronic  Reconnaissance 

TERCOM 

Terrain  Contour  Matching 

TFR 

Terrain  Following  Radar 

TISEO 

Target  Identification  System  Electro-Optical 

TRACALS 

Traffic  Control  and  Landing  System 

UHF 

Ultra  High  Frequency 

UHF-DF 

Ultra  High  Frequency  - Direction  Finder 

USAFE 

U.S.  Air  Forces  in  Europe 

USAFSS 

USAF  Security  Service 

UTM 

Universal  Transverse  Mercator 

VHF 

Very  High  Frequency 

VLSI 

Very  Large  Scale  Integration 

VOR 

Very  High  Frequency  Omnidirectional  Range 

V/STOL 

Vertical/Short  Take-Off  Landing 

WDA 

Weapon  Delivery  Aircraft 

WGS-72 

World  Geodetic  System,  1972 

wic 

Warranty  Information  Center 

w/w 

Wild  Weasel 

wx 

Weather 

APPENDIX  D 

DATA  CODES  FOR  AIRCRAFT  TYPES 
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Table  D-l  provides  a numerical  coding  scheme  for  identifying  aircraft 

I by  type  to  be  used  with  the  program  tracking  system  for  the  Avionics  Master 

Plan. 
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Table  D- 

1.  DATA  CODES  FOR  AIRCRAFT  TYPES 

Code 

Aircraft 

Code 

Aircraft 

Code 

Aircraft 

000 

All  major 

052 

EC-121G/T 

108 

UV-18B 

aircraft 

053 

EC-130E 

109 

AC-X 

types  in 

054 

EC- 135A 

110 

APF 

inventory- 

055 

EC-135N 

111 

ASTA 

general 

056 

EF-111A 

112 

ATCA 

application 

057 

EC-135C 

113 

ATF 

001 

A-7D 

058 

EC-135G 

114 

AV-X 

002 

A-10A 

059 

F-105G 

115 

FAC-X 

003 

A- 37b 

060 

F-105F 

116 

FOI  (F-15) 

004 

AC-130A 

061 

F-105D 

117 

RF-X 

005 

0-2  A 

062 

F-4C 

118 

BGM-34C 

006 

OV-10A 

063 

F-4D 

119 

Compass  Cope 

007 

0-2B 

064 

F-4E 

120 

SCMC 

008 

AC- 13 OH 

065 

F-4G 

121 

ASA 

009 

Sot  Used 

066 

F-5B 

122 

FWX 

010 

8-1 

067 

F/TF-15A 

123 

FMI 

Oil 

B-52D 

068 

F-16A 

124 

ETF 

012 

3-52G 

069 

F-100D/F 

125 

ACF 

013 

B-52H 

070 

F-101B 

126 

E-X 

014 

B-57C 

071 

F/TF-104G 

127 

OCTA 

015 

FB-111A 

072 

F-105B 

128 

Not  Used 

016 

B-52F 

073 

F-106A 

129 

AMST-CT 

017 

Not  Used 

074 

F-111A 

130 

F-5E 

018 

C-140B 

075 

F-111D 

131 

F-5F 

019 

VC-9C 

076 

F-111E 

132 

F-15A 

020 

C-5A/B 

077 

F-111F 

133 

F-15B 

021 

VC-6A 

078 

F-15  Intercept 

134 

F-15C 

022 

C-7A 

079 

EC-135P 

135 

F-15D 

023 

C-9A 

080 

Not  Used 

136 

HC-130N 

024 

C-12A 

081 

Not  Used 

137 

HC-130P 

025 

YC-14/15 

082 

HH-1H 

138 

VC/C- 13  ID 

026 

YC-97L 

083 

TH/UH-1F 

139 

VC/C-131E 

027 

C-118A 

084 

CH-3E 

140 

F-106B 

028 

C-123K 

085 

HH-53B 

141 

AQM-34L 

029 

C-130K 

086 

HARV 

142 

AQM-34M 

030 

C-130B 

087 

Not  Used 

143 

AQM-34V 

031 

C-130D 

088 

Not  Used 

144 

HH-3E 

032 

C-130E 

089 

DC-130H 

145 

H-X 

033 

C-130H 

090 

RC-130A 

146 

RC-X 

034 

HC-130H 

091 

RC/135A/D/ 

147 

ARPV 

035 

VC/C-131B 

M/S/T/U/V/ 

148 

TR-1 

036 

NC/C-131H 

092 

RF-4C 

149 

T-38B 

037 

C/NC-135A 

093 

RF-101C 

150 

F-101F 

038 

C-135B/C 

094 

SR-71A/B 

151 

UH-1N 

039 

KC-135A 

095 

WC-130E 

152 

UH-1P 

040 

VC-137B/C 

096 

WC-135B 

153 

F-16B 

041 

C-140A 

097 

Not  Used 

154 

HH-53C 

042 

YC-141B 

098 

Not  Used 

155 

CH-53C 

043 

EC-135H 

099 

T-33A 

156 

C/NC-141A 

044 

EC-13 5 J 

100 

T-37B 

157 

KC-135Q 

045 

EC-135K 

101 

T-38A 

158 

WC-130H 

046 

EC-135L 

102 

T-39A/B/F 

159 

UH-X 

047 

E-3A 

103 

T-41C 

999 

Specific 

048 

E-4A/B 

104 

T-43A 

aircraft 

049 

EB-57B 

105 

Not  Used 

application 

050 

B/EB-57E 

106 

U-2 

but  type(s) 

051 

EC-121C/S 

107 

U-4B 

not  certain 
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